@Pytal and @jancborchardt both of your comments are now implemented, thank you!

Slight request to the design team.
I think this is a bit technical looking and not super clear we're displaying filters.
Couldn't we add a label before this set of buttons/menus ?

The select menu is a bit more straightforward, as we display a summary of the selection before, and the actions labels speak for themselves with a verb in it

Maybe something like that (very rough mockup, but you get the idea)

EDIT: or aligning it with the selection checkbox instead

Slight request to the design team.

I agree but can we do this in a follow up as this one here is fixing a regression from beta 1?

Maybe something like that (very rough mockup, but you get the idea)

(Just a note:) I really like this, but would still let the chips flow to the left side under the "filter" as otherwise the space is very limited on smaller devices.

I agree but can we do this in a follow up as this one here is fixing a regression from beta 1?

Absolutely! Sorry, I thought I approved already!! 🙈

don't push, i will merge and compile assets with #46870

mh, cannot.

will build locally and force-merge. test was all green.

Google Drive has the filters listed without a label as well, so it could be fine. Also, the "Filters" text and icon adds even more noise to the file list.

For reference this is how Google Drive and Dropbox do the filters, no label: #43241

@jancborchardt are you intentionally replying to a merged pull request?

For reference this is how Google Drive and Dropbox do the filters, no label: #43241

I guess the left padding is what makes it look weird in my opinion :)
No Google nor Dropbox does it

I guess the left padding is what makes it look weird in my opinion :)
No Google nor Dropbox does it

• I agree, the left padding is unnecessary plus the filters keyword should not be added at all users can figure that out.
• The filters should probably come before the recommended section (and those should be filter too)

But these should be moved to a follow up ticket/issue since this is already merged and might be spam-ish.

The filters should probably come before the recommended section (and those should be filter too)

This was discussed before and it is the same as with rich workspaces:
The filters should be directly above the file list content. But agree please move discussion to separate ticket :)

It's not entirely clear to me, but... is this going to be full-width search presentation? As in, full-width of the page, not just a pull-down menu with limited view space? It looks like yes, but I would like to have this clarified.

Also, is this going to be able to present much larger amounts of results than just 10, and expanding by 10, each time?

Don't play with my heart! I've wanted to go back multiple Search overhauls for years! D:

@BloodyIron currently it only allows for filtering within the current place you are in within files but yes, actual search is also being looked into but not there yet. it is "in-app" so it is within the files user interface itself. You can already try it out with the v30 beta releases -but again, currently it only implemented filtering since search is a more complex implementation.

@BloodyIron currently it only allows for filtering within the current place you are in within files but yes, actual search is also being looked into but not there yet. it is "in-app" so it is within the files user interface itself. You can already try it out with the v30 beta releases -but again, currently it only implemented filtering since search is a more complex implementation.

In the example of the "Files" app... is it recursive including and below the current scope when triggered? Or is it Files-wide (ALL the files!?) or...?